一.读写锁介绍
在Java并发包中常用的锁(如:ReentrantLock),基本上都是排他锁,这些锁在同一时刻只允许一个线程进行访问,而读写锁在同一时刻可以允许多个读线程访问,但是在写线程访问时,所有的读线程和其他写线程均被阻塞。读写锁维护了一对锁,一个读锁和一个写锁,通过分离读锁和写锁,使得并发性相比一般的排他锁有了很大提升。
二.读写锁的特性
ReentrantReadWriteLock的特性总结:
①基本性质:读锁是一个共享锁,写锁是一个独占锁。读锁能同时被多个线程获取,写锁只能被一个线程获取。读锁和写锁不能同时存在。
②重入性:一个线程可以多次重复获取读锁和写锁。
③锁降级:一个线程在已经获取写锁的情况下,可以再次获取读锁,如果线程又释放了写锁,就完成了一次锁降级。
④锁升级:ReentrantReadWriteLock不支持锁升级。一个线程在获取读锁的情况下,如果试图去获取写锁,将会导致死锁(后面会详细说明)。
⑤获取锁中断:提供了可中断的lock方法。
⑥重入数:读锁和写锁的重入上限为65535(所有线程获取的锁的总数,为什么是这个值后面会详细说明)。
⑦公平性:ReentrantReadWriteLock提供了公平&非公平两种工作模式。
三.ReentrantReadWriteLock类层次图
ReentrantReadWriterLock并不实现Lock接口,而是通过两个内部类实现Lock接口,分别是ReadLock和WriterLock类。与ReentrantLock一样,ReentrantReadWriterLock同样使用自己的内部类Sync(继承AbstractQueuedSynchronizer)实现CLH算法。
四.读写锁的接口
public interface ReadWriteLock {
/**
* Returns the lock used for reading.
*
* @return the lock used for reading
*/
Lock readLock();
/**
* Returns the lock used for writing.
*
* @return the lock used for writing
*/
Lock writeLock();
}
ReadWriteLock仅定义了获取读锁和写锁的两个方法,即readLock()和writeLock()方法,而其实现— ReentrantReadWriteLock,除了接口方法之外,还提供了一些便于外界监控其内部工作状态的方法。
ReentrantReadWriteLock展示内部工作状态的方法:
//返回当前读锁被获取的次数。该次数不等于获取读锁的线程数,
// 比如:仅一个线程,它连续获取(重进入)了n次读锁,那么占据读锁的线程数是1,但该方法返回n
int getReadLockCount()
//返回当前线程获取读锁的次数。该方法在Java 6 中加入ReentrantReadWriteLock
//中,使用ThreadLocal保存当前线程获取的次数,这也使得Java 6 的实现变得更//加复杂
int getReadHoldCount()
//判断写锁是否被获取
boolean isWriteLocked()
//返回当前写锁被获取的次数
int getWriteHoldCount()
五.《java并发编程的艺术》一书上读写锁的demo
package com.secondbook.thread.lock;
import java.util.HashMap;
import java.util.Map;
import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantReadWriteLock;
/**
* Created by w1992wishes on 2017/6/2.
*/
public class ReadWriterLockForCache {
static Map<String, Object> cache = new HashMap<>();
static ReentrantReadWriteLock lock = new ReentrantReadWriteLock();
static Lock r = lock.readLock();
static Lock w = lock.writeLock();
//获取key对应的value
public static final Object get(String key){
r.lock();
try {
return cache.get(key);
}finally {
r.unlock();
}
}
// 设置key对应的value,并返回旧的value
public static final Object put(String key, Object value){
w.lock();
try{
return cache.put(key, value);
}finally {
w.unlock();
}
}
// 清空所有的内容
public static final void clear(){
w.lock();
try {
cache.clear();
}finally {
w.unlock();
}
}
}
ReadWriterLockForCache组合一个非线程安全的HashMap作为缓存的实现,同时使用读写锁的读锁和写锁来保证ReadWriterLockForCache是线程安全的。在读操作get(String key)方法中,需要获取读锁,这使得并发访问该方法时不会被阻塞。写操作put(String key,Object value)方法和clear()方法,在更新HashMap时必须提前获取写锁,当获取写锁后,其他线程对于读锁和写锁的获取均被阻塞,而只有写锁被释放之后,其他读写操作才能继续。ReadWriterLockForCache使用读写锁提升读操作的并发性,也保证每次写操作对所有的读写操作的可见性,同时简化了编程方式。
六.读写锁的实现分析
ReentrantReadWriterLock使用一个32位的int类型来表示锁被占用的线程数(ReentrantLock中的state),如果在一个整型变量上维护多种状态,就需要“按位切割使用”这个变量,高16位用来表示读锁占有的线程数量,用低16位表示写锁被同一个线程申请的次数。
上图是一个划分图,表示一个线程已经获取了写锁,且重进入了两次,同时也连续获取了两次读锁。
读写锁是通过位运算迅速确定读和写各自的状态。假设当前同步状态值为S,写状态等于S&0x0000FFFF(将高16位全部抹去),读状态等于S>>>16(无符号补0右移16位)。当写状态增加1时,等于S+1,当读状态增加1时,等于S+(1<<16),也就是S+0x00010000。
根据状态的划分能得出一个推论:S不等于0时,当写状态(S&0x0000FFFF)等于0时,则读状态(S>>>16)大于0,即读锁已被获取。
6.1 读锁的获取
写锁是一个支持重进入的排它锁。如果当前线程已经获取了写锁,则增加写状态。如果当前线程在获取写锁时,读锁已经被获取(读状态不为0)或者该线程不是已经获取写锁的线程,则当前线程进入等待状态。
读锁的lock方法在ReentrantReadWriteLock中:
public void lock() {
sync.acquireShared(1);
}
sync.acquireShared方法存在于AbstractQueuedSynchronizer类中:
public final void acquireShared(int arg) {
if (tryAcquireShared(arg) < 0)
doAcquireShared(arg);
}
ReentrantReadWriteLock中的tryAcquire:
protected final int tryAcquireShared(int unused) {
/*
* Walkthrough:
* 1. If write lock held by another thread, fail.
* 2. Otherwise, this thread is eligible for
* lock wrt state, so ask if it should block
* because of queue policy. If not, try
* to grant by CASing state and updating count.
* Note that step does not check for reentrant
* acquires, which is postponed to full version
* to avoid having to check hold count in
* the more typical non-reentrant case.
* 3. If step 2 fails either because thread
* apparently not eligible or CAS fails or count
* saturated, chain to version with full retry loop.
*/
Thread current = Thread.currentThread(); //@1 start
int c = getState();
if (exclusiveCount(c) != 0 &&
getExclusiveOwnerThread() != current)
return -1; // @1 end
int r = sharedCount(c);
if (!readerShouldBlock() &&
r < MAX_COUNT &&
compareAndSetState(c, c + SHARED_UNIT)) { // @2
if (r == 0) { //@21
firstReader = current;
firstReaderHoldCount = 1;
} else if (firstReader == current) { //@22
firstReaderHoldCount++;
} else { // @23
HoldCounter rh = cachedHoldCounter;
if (rh == null || rh.tid != current.getId())
cachedHoldCounter = rh = readHolds.get();
else if (rh.count == 0)
readHolds.set(rh);
rh.count++;
}
return 1;
}
return fullTryAcquireShared(current); // @3
}
@1,start--end ,如果有线程已经抢占了写锁,并且不是当前线程,则直接返回-1,通过排队获取锁。
@2,如果线程不需要阻塞,并且获取读锁的线程数没有超过最大值,并且使用 CAS更新共享锁线程数量成功的话;表示成获取读锁,然后进行内部变量的相关更新操作;先关注一下,成功获取读锁后,内部变量的更新操作。
@21,如果r=0, 表示,当前线程为第一个获取读锁的线程。
@22,如果第一个获取读锁的对象为当前对象,将firstReaderHoldCount 加一。
@23,成功获取锁后,如果不是第一个获取多锁的线程,将该线程持有锁的次数信息,放入线程本地变量中,方便在整个请求上下文(请求锁、释放锁等过程中)使用持有锁次数信息。
@3,如果CAS失败或readerShouldBlock方法返回true,我们调用fullTryAcquireShared方法继续试图获取读锁。fullTryAcquireShared方法是tryAcquireShared方法的完整版,或者叫升级版,它处理了CAS失败的情况和readerShouldBlock返回true的情况。
readerShouldBlock区分公平和非公平模式两种:
公平模式下,根据等待队列中在当前线程之前有没有等待线程来判断:
final boolean readerShouldBlock() {
return hasQueuedPredecessors();
}
而在非公平模式下:
final boolean readerShouldBlock() {
/* As a heuristic to avoid indefinite writer starvation,
* block if the thread that momentarily appears to be head
* of queue, if one exists, is a waiting writer. This is
* only a probabilistic effect since a new reader will not
* block if there is a waiting writer behind other enabled
* readers that have not yet drained from the queue.
*/
return apparentlyFirstQueuedIsExclusive();
}
调用了apparentlyFirstQueuedIsExclusive方法:
final boolean apparentlyFirstQueuedIsExclusive() {
Node h, s;
return (h = head) != null &&
(s = h.next) != null &&
!s.isShared() &&
s.thread != null;
}
该方法如果头节点不为空,并头节点的下一个节点不为空,并且不是共享模式【独占模式,写锁】、并且线程不为空,则返回true。
这个方法判断队列的head.next是否正在等待独占锁(写锁)。当然这个方法执行的过程中队列的形态可能发生变化。这个方法的意思是:读锁不应该让写锁始终等待。
现在再来看fullTryAcquireShared方法:
final int fullTryAcquireShared(Thread current) {
/*
* This code is in part redundant with that in
* tryAcquireShared but is simpler overall by not
* complicating tryAcquireShared with interactions between
* retries and lazily reading hold counts.
*/
HoldCounter rh = null;
for (;;) {
int c = getState();
if (exclusiveCount(c) != 0) {
if (getExclusiveOwnerThread() != current)
return -1;
// else we hold the exclusive lock; blocking here
// would cause deadlock.
} else if (readerShouldBlock()) {
// Make sure we're not acquiring read lock reentrantly
if (firstReader == current) {
// assert firstReaderHoldCount > 0;
} else {
if (rh == null) {
rh = cachedHoldCounter;
if (rh == null || rh.tid != getThreadId(current)) {
rh = readHolds.get();
if (rh.count == 0)
readHolds.remove();
}
}
if (rh.count == 0)
return -1;
}
}
if (sharedCount(c) == MAX_COUNT)
throw new Error("Maximum lock count exceeded");
if (compareAndSetState(c, c + SHARED_UNIT)) {
if (sharedCount(c) == 0) {
firstReader = current;
firstReaderHoldCount = 1;
} else if (firstReader == current) {
firstReaderHoldCount++;
} else {
if (rh == null)
rh = cachedHoldCounter;
if (rh == null || rh.tid != getThreadId(current))
rh = readHolds.get();
else if (rh.count == 0)
readHolds.set(rh);
rh.count++;
cachedHoldCounter = rh; // cache for release
}
return 1;
}
}
}
首先检查是否有其他线程正在持有写锁,如果是,直接返回false。
如果没有线程正在持有写锁,则调用readerShouldBlock检测当前线程是否应该进入等待队列。就算readerShouldBlock方法返回true,原因可能因为当前是公平模式或者队列的第一个等待线程(head.next)正在等待写锁,也不能直接返回false,因为返回false意味着当前线程将要进入等待队列(见AQS的acquireShared方法),原因是:①如果当前线程正在持有读锁,且这次读锁的重入被放入等待队列,万一之前队列中有线程正在等待写锁,将会导致死锁;②另一种情况是当前线程正在持有写锁,且这次读锁的“降级申请”被放入等待队列,如果队列中之前有线程正在等待锁,不论等待的是写锁还是读锁,都将导致死锁。
成功获取读锁,后续就是更新readHolds等内部变量。
如果返回-1,那么需要排队申请,具体要看acquireShared方法中的doAcquireShared(arg)。
private void doAcquireShared(int arg) {
final Node node = addWaiter(Node.SHARED);
boolean failed = true;
try {
boolean interrupted = false;
for (;;) {
final Node p = node.predecessor();
if (p == head) {
int r = tryAcquireShared(arg);
if (r >= 0) {
setHeadAndPropagate(node, r);
p.next = null; // help GC
if (interrupted)
selfInterrupt();
failed = false;
return;
}
}
if (shouldParkAfterFailedAcquire(p, node) &&
parkAndCheckInterrupt())
interrupted = true;
}
} finally {
if (failed)
cancelAcquire(node);
}
}
读锁的申请的申请流程图如下:
6.2 读锁的释放
public void unlock() {
sync.releaseShared(1);
}
readLock的unlock方法调用AQS提供的releaseShared方法实现:
public final boolean releaseShared(int arg) {
if (tryReleaseShared(arg)) {
doReleaseShared();
return true;
}
return false;
}
自定义同步器Sync重写的tryReleaseShared方法:
protected final boolean tryReleaseShared(int unused) {
Thread current = Thread.currentThread();
if (firstReader == current) {
// assert firstReaderHoldCount > 0;
if (firstReaderHoldCount == 1)
firstReader = null;
else
firstReaderHoldCount--;
} else {
HoldCounter rh = cachedHoldCounter;
if (rh == null || rh.tid != getThreadId(current))
rh = readHolds.get();
int count = rh.count;
if (count <= 1) {
readHolds.remove();
if (count <= 0)
throw unmatchedUnlockException();
}
--rh.count;
}
for (;;) {
int c = getState();
int nextc = c - SHARED_UNIT;
if (compareAndSetState(c, nextc))
// Releasing the read lock has no effect on readers,
// but it may allow waiting writers to proceed if
// both read and write locks are now free.
return nextc == 0;
}
}
读锁的每次释放(线程安全的,可能有多个读线程同时释放读锁)均减少读状态,减少的值是(1<<16)。
6.3 写锁的获取与释放
写锁是互斥锁,相对读锁实现要简单一些,具体就不往下了。